Still applies and works with 23.7. Needed to re-enable DoH/DoT and select the correct certificate after the upgrade though.

out of curiosity, what use-case do you have for this feature? We have seen some discussion, but can not really find a clear reason to add the feature ourselves.

out of curiosity, what use-case do you have for this feature? We have seen some discussion, but can not really find a clear reason to add the feature ourselves.

@AdSchellevis
If you are running a wifi hot-spot (where the wifi is not encrypted), you want your DNS requests to be encrypted to prevent anyone being able to snoop your traffic on the air interface. Similar as you want to make all your connections through https. Current Android phones will first try to connect to the DNS server using DoT on port 853, and if it works will use that for any DNS queries.

@schreibubi The part I don't understand in this is, if Android contacts the dns server provided, why should it trust the certificate it received? I would expect this can only work with client configuration as well, which would make it less useful in common scenario's. Maybe (probably) I'm missing something, but without understanding the lay of the land, it would be difficult to incorporate a feature like this and describe it on our end.

@schreibubi The part I don't understand in this is, if Android contacts the dns server provided, why should it trust the certificate it received?

On Android, it works just fine with proper certificates issued by system-trusted CAs (notably Lets Encrypt). It currently does not work with user installed CAs and Google's effort to fix it is about non-existent. See
Private DNS over TLS is ignoring user installed CA

@AdSchellevis Take a look at this page from google: https://developers.google.com/speed/public-dns/docs/dns-over-tls
What I was referring to was the opportunistic privacy profile mentioned there. It protects against a passive attacker, but not an active one. Using DoT that way at least raises the bar for an attacker, so is better than doing nothing (i.e. unencrypted DNS). The client in this case can only verify that the certificate is signed by a valid CA, but not that it really talks to the server the user wants it to talk to (because the user did not specify the server name to use and it just used the DNS server specified by the DHCP response). There is BTW an IETF draft where the DHCP response will contain the DoT server name: https://www.ietf.org/archive/id/draft-ietf-add-ddr-10.html. Then the client will be able to verify the certificate the DoT server presents. Though DHCP will then become the weakest link in the chain....

When the user explicitly configures the DoT server, that will raise the bar even higher, though a capable enough active attacker will still be able to do a MITM attack when he can get a certificate in the DoT's server name. Preventing that attack vector would then require something like certificate pinning.

As always with security, it is about raising the bar. But a capable enough attacker with enough resources will always be able to circumvent your security...

With a browser trusted certificate, it might work, I'm a bit doubting if it remains functional in the long run as the trust situation from the clients perspective hasn't really improved in my humble opinion (a change of strategy from Google's end might change the world dramatically).

Although I certainly miss some context, if there would be a man-in-the-middle, why couldn't he/she do the exact same trick in this case by using a let's encrypt cert and sniff traffic in between? If trust is based on accepting any certificate signed by a trusted party, that shouldn't be too hard. Again, I likely miss some context which might explain why this wouldn't be possible when our end accepts tls from the client.

The main issue I do have with these additions is that there are multiple constraints involved before people are able to use the feature for which no documentation exists on our end, which has a high risk of creating a false sense of security when not properly used.

As always with security, it is about raising the bar. But a capable enough attacker with enough resources will always be able to circumvent your security...

I certainly agree, I'm just missing the part which bar is being raised, other then eaves dropping without intercepting traffic.

HTTPS == encrypted browser traffic. DoT == encrypted DNS traffic. There's nothing else those certificates have ever ensured,

DoT is no less secure than the unencrypted DNS over 53, if anything. Anything else is up to the network admin to implement properly, like with any other feature. If the firewall admin does not wish to implement this, they simply won't enable the feature.

I really do not get the point of discussion here.

It's quite simple, if we're not able to explain why a certain feature would be useful and how an administrator should be able to utilize it, we should not consider adding it. Our product is being used by all sorts of people and we aim to keep it accessible.

Unclear features lead to future support nightmares. In order to incorporate this (or any other feature in core), someone from our team will likely need to spend time on it in some way (refactoring code, writing documentation and answering questions).
People seeking to build advanced setups not supported by our gui are often able to use custom hooks, which is also the case for unbound (https://docs.opnsense.org/manual/unbound.html#advanced-configurations).

So that's the discussion, nothing more, nothing less. It's currently not a priority on our end to work on this, that might change if someone is able to explain suitable use-cases and constraints, you never know.

So let's try to keep the discussion constructive and try to find valid use-cases in stead of complaining the discussion isn't clear.

Well, all I can say is that this patch works perfectly fine with DoT-capable clients - as long as the certificate can be validated by the client's OS resolver. That is very much expected and works exactly as designed. Android bugs ignored by Google should not prevent admins from configuring useful DNS resolver features which are working just fine on other OSes (such as Windows 11) via the GUI.

(As for the hooks, I cannot see an easy way to pass a selected certificate to those.)

There is another use case. Firefox doent't support ECH without DoH. The only way to use ECH with local DNS resolver is to connect to it via DoH.